Right-clicking a player on `?p=servers` and choosing "Kick player" loads
the kickit iframe, which until now ran the post-ban-completion code path
unconditionally — emitting the rcon kick reason
"You have been banned by this server, check $domain for more info" and
re-attributing whatever active ban happened to share the SteamID to the
kick target's server (UPDATE :prefix_bans SET sid = ... WHERE authid = ...
AND RemovedBy IS NULL). The reporter on #1439 saw the wrong message; the
silent audit-trail corruption was the worse half of the bug.

The fix carries an explicit `mode` signal end-to-end:

- The context menu's Kick URL now appends `&mode=kick` (the post-ban
  iframe embed inside `admin.bans.php`'s "Ban Added" dialog stays on the
  default `'ban'` mode).
- `admin.kickit.php` allowlists `$_GET['mode']` to `'ban'|'kick'`
  (anything else coerces to `'ban'` — backward-compat with pre-#1439
  callers that don't supply the param).
- `KickitView` carries the mode through to `page_kickit.tpl` which
  branches the `<title>` ("Kick player" vs "Ban player"), surfaces a
  `data-mode` attribute on the container for third-party theme styling,
  and forwards the value as `mode` on every `kickit.kick_player` JSON
  call.
- `api_kickit_kick_player` re-validates the mode and gates two things on
  it: the `:prefix_bans` UPDATE is skipped on kick mode (extracted into
  `_api_kickit_should_update_ban_sid` for testability + clarity), and
  the rcon kick reason is now "You have been kicked from this server"
  on kick mode (still "You have been banned by this server, check ..."
  on ban mode).
- The iframe's post-completion redirect lands the operator back on
  `?p=servers` for the kick flow (where they came from), preserving the
  existing `?p=admin&c=bans` destination for ban mode.

Coverage:

- `KickitTest` (15 cases, 82 assertions) — handler-shape coverage for
  both modes + the unknown-mode coercion, the rcon-message branch via
  `_api_kickit_build_kick_message`, and the ban-UPDATE gate via the new
  `_api_kickit_should_update_ban_sid` helper (incl. a static-analysis
  guard that the handler invokes the helper rather than inlining the
  `$mode === 'ban'` check around the UPDATE).
- `kickit-iframe.spec.ts` adds an E2E case driving the full kick flow:
  title says "Kick player", `kickit.kick_player` payload carries
  `mode: 'kick'`, and the post-completion `window.location` flip lands
  on `index.php?p=servers` (anchored on real `waitForURL` against the
  actual 5s redirect timer — source-grep on the script body would
  silently accept a regression that deleted the kick-mode arm).
- `server-player-context-menu.spec.ts` updated to expect `&mode=kick`
  in the Kick item's href.

Documentation in AGENTS.md (context-menu prose + "Where to find what"
table + regression-guards section) extended to spell the `mode`
contract end-to-end so future readers don't re-discover the failure
mode.

Adversarial reviewer pass also caught: ban-mode UPDATE SQL was
incorrectly transcribed as `removetype = 'X'` in AGENTS.md (now
`sid = :sid WHERE authid = :authid AND RemovedBy IS NULL`); the new
unit tests now also assert the `mode` field is consumed by the handler
and not echoed back in the API response.

Fixes: #1439